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REMARKS 

Claims 1,11 and 26 are amended to more clearly define the invention. 

Independent claims 28 and 29 are added. Claim 28 is a combination of 
claim 2 and claim 1 (prior to the claim 1 amendment made herein)* Claim 29 is a 
combination of claim 6 and claim 1 (prior to the claim 1 amendment made herein). 

Support for the amendments that indicate the system initiates 
scheduling of a task sequence in response to receiving a '^message identifying 
occurrence of said event" and "determination pre-conditions associated with said task 
sequence are satisfied" (e.g., of claim 1), is found in the Application on page 8 lines 
26 - 28 and page 12 lines 28-31 and in Figures 2 and 6 and other places. 

/. Rejection under 35 J/.S.C 102(b) 

Claims 1, 2, 3, 6, 9-13, 19-23, 26 and 27 are rejected under 35 U.S.C 
102(b) as being anticipated by U.S. Patent 5,692,125 - Schloss et al. These claims, as 
amended, are deemed to be patentable for the reasons given below. 

Amended claim 1 recites in "a system for scheduling first process, 
comprising a set of tasks, to be performed by at least one individual to support 
healthcare delivery, a method for processing an event representing a change in 
circumstances potentially affecting healthcare delivered to a patient" comprising 
"associating in a repository, at least one event potentially affecting healthcare 
delivered to a patient with a sequence of tasks to be performed to support healthcare 
delivery to said patient; receiving a message identifying occurrence of said event; 
determining by using said repository, a particular sequence of tasks to be performed, 
in response to receiving said message identifying occurrence of said event; and 
initiating scheduling of performance of said particular sequence of tasks by at least 
one individual in response to receiving said message identifying occurrence of said 
event and determination pre-conditions associated with said task sequence are 
satisfied and said tasks of said task sequence are ready for performance by said at 
least one individual". These features are not shown (or suggested) in Schloss. 

The method of amended claim 1 supports "initiating scheduling of 
performance of said particular sequence of tasks by at least one individual in response 
to receiving said message identifying occurrence of said event and determination pre- 
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conditions associated with said task, sequence are satisfied". The claimed arrangement 
initiates scheduling "in response to receiving said message identifying occurrence 
of said event and determination pre-conditions associated with said task sequence 
are satisfied and said casks of said task sequence are ready for performance by said 
at least one individual". This is not shown or suggested in Schloss. This approach is 
fundamentally different to the Schloss approach. The claimed arrangement initiates 
scheduling of tasks by "determining'* a "particular sequence of tasks to be performed 
in response to receiving said message identifying occurrence of said event". It does 
this by using a repository "associating at least one "event potentially affecting 
healthcare delivered to a patient with a sequence of tasks to be performed to support 
healthcare delivery to said patient; receiving a message identifying occurrence of said 
event". The claimed system does not schedule tasks until an appropriate event 
message is received and pre-conditions for executing the tasks are satisfied and the 
tasks of said task sequence are ready for performance by the at least one individual 

Schloss discloses "a system and method that schedules one or more 
events or event groups subject to conditions" (Schloss column 2 lines 28-32". This 
is in direct contrast with the claimed system which does not schedule tasks until an 
appropriate event message is received and **pre-conditions" are "satisfied" and the 
tasks Of said task sequence are ready for performance by the at least one individual. 
In Schloss, following scheduling of a task "there are dynamic conditions that must be 
checked (at a prepare to perform time 252 t 258) and honored before performing 
event 1 at the performance time 256" (column 4 lines 41-43). The claimed 
arrangement is not shown or suggested in Schloss which teaches a system 
fundamentally different to that of the claimed arrangement. It is the inefficiency 
involved in altering and updating healthcare worker schedules because of the need to 
update scheduling at a "prepare to perform time" that is addressed in the claimed 
system. The claimed arrangement provides substantial logistical and efficiency 
advantages in a modern complex healthcare environment (see Application page 5 
lines 19-23). 

Schloss teaches the fundamentally different approach of initiating 
scheduling of tasks and subsequently determining if the tasks are still appropriate at 
a "prepare to perform time" by determining whether to cancel, alter or modify tasks if 
dynamic conditions associated with the tasks are not satisfied. Specifically, Schloss in 
the Abstract states in "a scheduling system, events and/or groups of events are 
checked at a scheduling time to insure that certain fixed conditions associated with 
the event(s) are satisfied. The events are also checked at one or more times, between 
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scheduling time and a performance time (when the event(s) are to be performed), 
called ""prepare to perform timeCs)." At the prepare to perform time(s), certain 
dynamic conditions and/or data associated with the events are checked to determine 
whether the dynamic conditions are satisfied... If one or more of the dynamic 
conditions are not satisfied, the cvcnt(s) are... modified by cancelling, altering or 
postponing". Note, an event is defined differently in the claimed arrangement to the 
definition in Schloss. In Schloss an "event" is "any occurrence to be scheduled** 
(Schloss column 3 line 8) whereas in the claimed arrangement an "event" represents a 
"change in circumstances potentially affecting healthcare delivered to a patient". 
Schloss nowhere shows or suggests the claimed system which does not schedule 
tasks until an appropriate event message is received and "pre-conditions" are 
"satisfied" and the "tasks of said task sequence are ready for performance" by the 
at least one individual. Consequently, withdrawal of the rejection of amended claim 1 
under 35 USC 102(b) is respectfully requested. 

Dependent claim 2 is considered to be patentable based on its 
dependence on claim 1 . Claim 2 is also considered to be patentable because Schloss 
does not show (or suggest) "in response to examining predetermined information and 
said occurrence of said identified event, substituting at least one of said particular 
tasks for a task of an existing scheduled task sequence". Schloss nowhere mentions or 
contemplates "substituting" a task for another task of a workflow. Schloss in column 
8 lines 27-29 (or elsewhere) does not contemplate, discuss or mention substituting a 
task for another task. The term "substituting" as defined and used in the application 
comprises replacing a task with another task, for example. This is evident from the 
application on page 10 lines 1-5 which indicates "Selection of item 625 results in 
replacement of a scheduled default workflow process (or in another embodiment, 
particular identified tasks of the default workflow process)". Schloss in column 8 
lines 27-29 fails to show, suggest mention or allude to such a feature. 

Dependent claim 3 recites a method in which "said message includes 
an event identifier identifying said event and is generated by a second process 
comprising a second set of tasks and including the activity of also receiving an 
identifier identifying a particular instance of said first process". These features, in 
combination with the features of claim 1 , are not shown or suggested in Schloss. 

Contrary to the Rejection statement on page 3 and elsewhere, Schloss 
in column 8 lines 21-22 does not show or suggest use of an 'Identifier identifying a 
particular instance" of a process. An "instance of a process" is to be interpreted as a 
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v *copy (an instance) of the desired event associated particular workflow process 1 " 
(Application page 8 lines 28-30) i.e. an instance of a process is a copy of a process. 
This is also the meaning attributed to the term by one of ordinary skill in the art at the 
time of the invention. The recognition of the patentee as "his or her own 
lexicographer" holds even when the patentee defined the word more broadJy than its 
ordinary meaning (Jack Guttman T Inc. v. Kopykake Enter., Inc., 302 F.3d 1352, 1360, 
64 U.S.P.Q.2d (BNA) 1302, 1307 (Fed, Cir. 2002), If the patent specification defines 
a claim term, either expressly or by clear implication, it acts as a dictionary for 
interpreting that claim term (Jack Guttman, 302 R3d 1352, 1360, 64 U.S.P.Q^d 
(BNA) 1302 at 1307 (Fed, Cir, 2002), Vitronics Corp. v. Conceptronic Inc., 90 F.3d 
at 1582, 39 U.S.P.Q.2d (BNA) at 1577. Schloss in column 8 lines 21-22 does not 
show or suggest use of an "identifier identifying a particular" copy of a process. 
Schloss in column 8 lines 21-22 relied on in the Rejection merely mentions "if the 
event is part of an event group, each event 210 in the event group 260 will require the 
identifier 305". This has nothing to do with an instance or copy of process. 

Schloss also fails to show or suggest use of an "event identifier** 
identifying an event comprising a "change in circumstances potentially affecting 
healthcare delivered to a patient". An "event" as used in Schloss is "any occurrence to 
be scheduled" i.e. a task (Schloss column 3 line 8) and is NOT a "change in 
circumstances potentially affecting healthcare delivered to a patient". Schloss in 
column 4 lines 42-44, column 7 lines 55-59 and column 8 lines 27-35 does not show 
or suggest such an "event identifier". 

Dependent claim 6 is considered to be patentable based on its 
dependence on claim 1 and for reasons given in connection with claim 3. Claim 6 is 
also considered to be patentable because Schloss does not show (or suggest) the 
feature combination of claim 6 involving "associating in a repository, said event with 
a process instance identifier identifying an instance of a process comprising said 
sequence of tasks". As previously explained in connection with claim 3, Schloss does 
not show or suggest use of a "process instance identifier". Schloss also does not 
suggest "associating in a repository, said event with a process instance identifier 
identifying an instance of a process comprising said sequence of tasks". Contrary to 
the Rejection statement on page 4, the event group template and pointer to a header 
identifier of Schloss column 7 lines 55-59 has nothing to do with a "process instance 
identifier". 
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Dependent claim 9 is considered to be patentable based on its 
dependence on claim 1. 

Dependent claim 10 is considered to be patentable for reasons given in 
connection with claim 1 and because of its dependence on claim 1. Claim 10 is also 
considered to be patentable because Schloss does not show (or suggest) the feature 
combination involving "receiving information identifying a particular individual task 
of an existing scheduled task sequence and including the activity of adapting said 
existing scheduled task sequence by initiating processing of said existing scheduled 
task sequence from said identified particular individual task in response to occurrence 
of said event". Column 12 lines 14-16 relied on in the Rejection does NOT show or 
suggest "adapting said existing scheduled task sequence by initiating processing of 
said existing scheduled task sequence from said identified particular individual task 
in response to occurrence of Said event*\ These injection and booster injection task 
relied on do not show the relationship claimed of "adapting said existing scheduled 
task sequence by initiating processing of said existing scheduled task sequence from" 
a particular task. 

Amended independent claim 11 is considered to be patentable for 
reasons given in connection with claim 1. 

Dependent claim 12 is considered to be patentable based on its 
dependence on claim 11. Claim 12 is also considered to be patentable because Schloss 
does not show (or suggest) the feature combination of claim 11 in which "said 
associated parameter is for use by multiple different process task sequences and is 
stored at a location available for access by said multiple different process task 
sequences"* Contrary to the Rejection statement on page 6 7 Schloss provides no 35 
USC 112 compliant enabling disclosure in Figure 2, column 3 lines 40-65, column 15 
lines 46-53 or elsewhere, of providing global parameters "stored at a location 
available for access by said multiple different process task sequences". 

Dependent claim 13 is considered to be patentable based on its 
dependence on claim 1 L Claim 13 is also considered to be patentable because Schloss 
does not show (or suggest) the feature combination including "verifying said 
associated parameter is compatible with predetermined value criteria as a pre- 
condition to providing said parameter to said predetermined process'*. The claimed 
arrangement initiates "scheduling of performance of said particular process in 
response to... determination pre-conditions associated with said task sequence are 
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satisfied a^d said casks of said task sequence are ready for performance by said at 
least one individual". Consequently, "verifying said associated parameter is 
compatible with predetermined value criteria" is performed prior to ''initiating 
scheduling of performance of said particular process". In contrast Schloss initiates 
scheduling only on "fixed conditions" and not in response to such dynamic 
conditions. 

Dependent claim 19 is considered to be patentable based on its 
dependence on claim 11 and for reasons given in connection with claims 3, 7, 8 and 
17. Claim 19 is also considered to be patentable because Schloss does not show (or 
suggest) "associating in a repository" an "event with a process instance identifier 
identifying an instance of said process comprising said sequence of tasks". 

Independent claim 20 is considered to be patentable for reasons given 
in connection with claims 1, 3 and 6. Claim 20 is also considered to be patentable 
because Schloss does not show (or .suggest) "a method for processing an event 
representing a change in circumstances potentially affecting healthcare delivered to a 
patient" comprising "associating in a repository, at least one event potentially 
affecting healthcare delivered to a patient with a process instance identifier 
identifying an instance of a process comprising a sequence of tasks to be performed to 
support healthcare delivery to a patient; in response to occurrence of an event in a first 
process, receiving at least one message identifying during said first process and 
identifying a parameter associated with said event; acquiring said parameter 
associated with said event and providing said parameter to an instance of a second 
process identified using said repository; and adapting said instance of said second 
process by scheduling performance of a particular set of tasks in response to receiving 
said at least one message", Schloss does not show (or suggest) "associating in a 
repository, at least one event potentially affecting healthcare delivered to a patient 
with a process instance identifier identifying an instance of a process comprising a 
sequence of tasks", Schloss does not recognize or contemplate the use of process 
instance identifiers (such identifiers identify copies of a process comprising a defined 
sequence of tasks, for example), 

Schloss mentions templates as being "event groups with some omitted 
information that is provided by a user at scheduling time. Templates are used to 
facilitate the scheduling of common events and/or event groups'* (Schloss column 4 
line 66 to column 5 line 7). However, Schloss in column 8 lines 35-37 or elsewhere 
provides no mention, recognition or discussion of the use of "process instances" or 
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"process instance identifiers". Schloss similarly does not show or suggest "adapting 
said instance of said second process by scheduling performance of a particular set of 
tasks in response to receiving said at least one message". Column 8 lines 35-37 
suggests nothing about process instances at all. 

Dependent claim 21 is considered to be patentable based on its 
dependence on claim 20 and for reasons given in connection with claim 10. Claim 21 
is aJso considered to be patentable because Schloss does not show (or suggest) the 
feature combination of claim 21 together with "including the activity of receiving an 
identifier identifying a particular individual task in said second process and wherein 
said adapting activity comprises initiating processing of said second process from 
said particular individual task in response to receiving said at least one message 
identifying occurrence of said event and determination said parameter is within 
predetermined acceptability criteria"* Schloss in column 12 lines 16-35 and column 4 
lines 41-54 does not suggest a feature combination as provided by claim 21 . 

Dependent claim 22 is considered to be patentable based on its 
dependence on claim 20 and for reasons given in connection with claim 12. 

Dependent claim 23 is considered to be patentable based on its 
dependence on claim 20. Claim 23 is also considered to be patentable because 
Schloss does not show (or suggest) the feature combination involving "sharing data 
between said first and second process comprising sharing at least one of, (a) an event 
identifier identifying said event, (b) a process identifier identifying said first process 
and (c) an identifier identifying a particular instance of said first process". As 
previously explained an "event" as defined in Schloss comprises "any occurrence to 
be scheduled** (Schloss column 3 line 8) whereas in the claimed arrangement an 
"event" represents a "change in circumstances potentially affecting healthcare 
delivered to a patient". Consequently, Schloss in column 8 lines 21-26 or elsewhere 
does not suggest a feature combination as provided by claim 23. Column 8 lines 21- 
26 merely refers to event identifiers of events comprising "any occurrence to be 
scheduled" (Schloss column 3 line 8) and have nothing to do with "sharing data" 
between a "first and second process". 

Amended independent claim 26 is considered to be patentable for 
reasons given in connection with claim 1. Claim 26 is also considered to be patentable 
because Schloss does not show (or suggest) a "system for processing an event 
representing a change in circumstances potentially affecting healthcare delivered to a 
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patient, said system being for use in scheduling a first process comprising a set of 
tasks to be performed by at least one individual to support healthcare delivery" 
comprising "at least one repository associating at least one event potentially affecting 
healthcare delivered to a patient with a sequence of tasks to be performed to support 
healthcare delivery to said patient; a communication interface for receiving a message 
identifying occurrence of said event; an event analyzer for using said at least one 
repository and for applying predetermined rules to interpret said identified event to 
determine a particular sequence of tasks to be performed in response to receiving said 
message identifying occurrence of said identified event; and a processor for initiating 
scheduling of performance of said particular tasks by at least one individual in 
response to said occurrence of said identified event and determination pre-conditions 
associated with said task sequence are satisfied and said tasks of said task sequence 
are ready for performance by said at least one individual". 

Schloss does not show (or suggest) 'initiating scheduling of 
performance of said particular tasks by at least one individual in response to said 
occurrence of said identified event and determination pre-conditions associated with 
said task sequence are satisfied and said tasks of said task sequence are ready for 
performance by said at least one individual", Schloss also does not suggest in column 
14 lines 41-56 (as relied on in the Rejection on page 9) **an event analyzer for using 
said at least one repository and for applying predetermined rules to interpret said 
identified event to determine a particular sequence of tasks to be performed in 
response to receiving said message identifying occurrence of said identified event". 
As previously explained an "event" as defined in Schloss comprises "any occurrence 
to be scheduled" i.e. a task (Schloss column 3 line 8) whereas in the claimed 
arrangement an "event" represents a "change in circumstances potentially affecting 
healthcare delivered to a patient". Consequently, Schloss does not suggest a feature 
combination as provided by claim 26. 

Amended dependent claim 27 is considered to be patentable based on 
its dependence on claim 26. Claim 27 is also considered to be patentable because 
Schloss does not show (or suggest) the feature combination of claim 27 including "at 
least one repository** that "associates said at least one event with a process instance 
identifier identifying an instance of a process comprising said sequence of tasks". As 
previously explained in connection with claim 20, Schloss does not suggest use of 
"process instance identifier" or such a feature combination at all. Consequently, 
withdrawal of the rejection of claims 1, 2, 3, 6, 9-13, 19-23, 26 and 27 under 35 
U.S.C 102(b) is respectfully requested. 
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//. Rejection under 35 U.S.C. 103(a) 

Claims 4, 7, 8, 15-18, 24 and 25 are rejected under 35 U.S.C. 103(a) a§ 
being unpatentable over U.S. Patent 5,692,125 - Schloss et al. in view of U.S. Patent 
6,401,138 - Judge et al. These claims are considered patentable for reasons given in 
connection with claim 1 and for the following reasons. 

Dependent claim 4 is considered to be patentable based on its 
dependence on claims 1 and 3. Claim 4 is also considered to be patentable because 
Schloss with Judge does not show (or suggest) "said particular instance of said first 
process comprises a particular use of said process for a specific patient". Contrary to 
the Rejection statements on page 7, neither Judge nor Schloss alone or together show 
or suggest use of "an event identifier identifying'* a "change in circumstances 
potentially affecting healthcare delivered to a patient" and that is "generated by a 
second process comprising a second set of tasks and including the activity of also 
receiving an identifier identifying a particular instance of said first process" 
comprising a "particular use of said process for a specific patient". As previously 
explained neither reference suggests use of such an "event identifier" or such a 
process "instance" identifier. Judge in column 21 lines 36-45» relied on in the 
Rejection, shows sharing patient context information between different executable 
applications and has no relevance to use of an identifier identifying a '^particular 
instance of said first process" for a particular use of said process" comprising a "set 
of tasks, to be performed by at least one individual to support healthcare delivery" for 
a "specific patient" as recited in claim 4. 

As previously explained in connection with claim 3, an "instance of a 
process" is to be interpreted as a "copy (an instance) of the desired event associated 
particular workflow process" (Application page 8 lines 28-30) i.e. an instance of a 
process is a copy of a process. This is also the meaning attributed to the term by one 
of ordinary skill in the art at the time of the invention. Schloss with Judge does not 
show or suggest use of an "identifier identifying a particular" copy of a process* 
Contrary to the Rejection statement on page 11, Judge in column 9 line 13 does not 
show or suggest use of an "identifier identifying a particular" copy of a process at 
all. The NT process ID reiied on is merely used to identify an application called by a 
Windows NT operating system. Specifically, "in order to identify the application with 
which each PCI_ApplicationC object is associated... the NT process ID, the NT 
thread ID, and the NT process create time (the values required to uniquely identify 
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an application under NT) are stored in the i_process!d 256, i_threadld 258, and 
i_createTime 260 members, respectively" (Judge column 9 lines 10-17). Therefore 
neither Judge nor Schloss individually or together contemplate or suggest use of an 
identifier identifying a "particular instance of said first process" for a "particular use 
of .said process" 

Dependent claim 7 is considered to be patentable based on its 
dependence on claim 1 and for reasons given in connection with claims 2-4. Claim 7 
is also considered to be patentable because Schloss with Judge does not show (or 
suggest) a system involving a "message" that "includes an event identifier identifying 
said event and a process identifier identifying a target process to be replaced by a 
predetermined process comprising said particular tasks". The Rejection on page 8 
relies on the erroneous premise that if a process has an identifier it would be obvious 
to use the identifier to identify a "target process to be replaced by a predetermined 
process comprising said particular tasks" in the context of the claim arrangement The 
Rejection provides no showing or suggestion or motivation in either cited reference 
for identifying a "target process to be replaced" in any context. These features 
advantageously enable efficient scheduling of workflow processes in a healthcare 
environment avoiding the inefficiency of prior processes as exemplified by the 
Schloss system. There is no recognition of the advantages of the claimed system nor 
any motivation or other reason for modifying the Schloss and Judge systems alone Oir 
together to include the claimed arrangement. 

Dependent claim 8 is considered to be patentable based on its 
dependence on claims 1 and 7 and for reasons given in connection with claims 2-7* 
Claim 8 is also considered to be patentable because Schloss (in column 5 lines 29-30) 
with Judge does not show (or suggest) a system involving "searching a database 
containing records indicating active processes and process instances to identify 
active process instances of said target process to be replaced". 

Dependent claim 15 is considered to be patentable based on its 
dependence on claim 1 1 and for reasons given in connection with claim 7. Claim IS is 
also considered to be patentable because Schloss with Judge does not show (or 
suggest) the feature combination of claim 15 in which "replacing scheduling of 
performance of another process with said scheduling of performance of said identified 
process". The Rejection provides no showing or suggestion or motivation in either 
cited reference, for "replacing scheduling of performance of another process with said 
scheduling of performance of said identified process". These features advantageously 
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enable efficient scheduling of workflow processes in a healthcare environment 
avoiding the inefficiency of prior processes us exemplified by the Schloss system. 
There is no recognition of the advantages of the claimed system nor any motivation or 
other reason for modifying the Schloss and Judge systems alone or together to include 
the claimed arrangement. 

Dependent claim 16 is considered to be patentable for reasons given is 
connection with claim 7. 

Dependent claim 17 is considered to be patentable based on its 
dependence on claims 11 and 16, Claim 17 is also considered to be patentable 
because Schloss with Judge dofcs not show (or suggest) "searching a database 
containing records indicating active processes and process instances to identify active 
process instances of said target process to be replaced". As previously explained in 
connection with claims 7 and 8, the Rejection provides no showing or suggestion or 
motivation in either cited reference for identifying a process to be "replaced" or of 
identifying "active process instances of said target process to be "replaced". These 
features advantageously enable efficient scheduling of workflow processes in a 
healthcare environment avoiding the inefficiency of prior processes as exemplified by 
the Schloss system. There is no recognition of the advantages of the claimed system 
nor any motivation or other reason for modifying the Schloss and Judge systems alone 
or together to include the claimed arrangement. Column 5 lines 29-30 of Schloss 
relied on in the Rejection on page 9 have nothing to do with replacing processes or 
active process instances. 

Dependent claim 18 is considered to be patentable based on its 
dependence on claim 1 1 and for reasons given in connection with claims 3, 1 H 8 and 
17. Claim 18 is also considered to be patentable because Schloss with Judge does not 
show (or suggest) "receiving information identifying active process instances and 
storing records in a database indicating said identified active process instances". 

Dependent claim 24 is considered to be patentable based on its 
dependence on claim 20 and for reasons given in connection with claims 3, 7 t 8 and 
17. 

Dependent claim 25 is considered to be patentable based on its 
dependence on claim 20 and for reasons given in connection with claims 3, 7, 8 and 
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17. Consequently withdrawal of the Rejection of claims 4, 7, 8, 15-18, 24 and 25 
under 35 USC 103(a) is respectfully requested. 

IIL Rejection under 35 U.S.C 103(a) 

Claims 5 and 14 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent 5,692,125 - Schloss et al, in view of U.S. Patent 
6,004,276 - Wright et al. These claims are considered patentable for reasons given in 
connection with claim 1 and for the following reasons. 

Dependent claim 5 recites a method in which 'filtering a plurality of 
received messages to identify said message identifying occurrence of an event 
potentially affecting healthcare delivered to a patient and excluding other messages 
immaterial to said healthcare delivered to said patient". These features, in 
combination with the features of claim 1* are not shown or suggested in Schloss in 
combination with Judge based on its dependence on claim 1 and for reasons given 
below. 

As recognized in the Rejection on page 12, Schloss fails to show or 
suggest 'filtering a plurality of received messages to identify said message 
identifying occurrence of an event potentially affecting healthcare delivered to a 
patient". However, the Rejection erroneously states Wright discloses this limitation in 
column 42 lines 37-41. Wright in this section states "events may be prioritized to 
allow filtering and masking during a query" and defines events as "the event type is 
the type or class of event (user-related, data transfer, etc.), and the event identifier is 
the event that occurred** (Wright column 39 lines 63-66). Wright therefore uses the 
term "event" to encompass computer system events such as data transfer etc. Wright 
also uses the term "event data*' to refer to data associated with a cardiac stress test 
*The text document segments of a report are generated from pre-test data, event data 
and post-test data. The pre-test data may include data such as patient demographics 
and the reason for the test. The event data preferably includes information such as a 
ten-second ECG analysis and measurements, blood pressure data and comments' 1 
(Wright column 65 lines 60-66). Consequently Wright does NOT show or suggest (or 
provide any 35 USC 112 enabling disclosure) of "filtering a plurality of received 
messages to identify said message identifying occurrence of an event potentially 
affecting healthcare delivered to a patient" and "excluding other messages immaterial 
to said healthcare delivered to said patient". 
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Incorporating die Wright system filtering in the scheduling system oX 
Schloss results in a system for initiating scheduling of tasks and subsequently 
determining if the tasks are still appropriate at a "prepare to perform time" involving 
filtering computer system messages indicating data transfers and the like and does 
NOT filter "a plurality of received messages to identify said message identifying 
occurrence of an event potentially affecting healthcare delivered to a patient". 
There is no suggestion in the combined references of use of an "identifier 
identifying a particular instance" of a process in combination with use of an "event 
identifier" identifying an event comprising a "change in circumstances potentially 
affecting healthcare delivered to a patient", Further, there is no recognition of the 
specific scheduling problem of inefficiency involved in altering and updating 
healthcare worker schedules because of the need to update scheduling at a "prepare to 
perform time" that is addressed in the claimed system. There is also no other reason 
or motivation in either reference for providing the claimed feature arrangement. 
Consequently withdrawal of the Rejection of amended claim 5 under 35 USC 103(a) 
is respectfully requested. 

Amended dependent claim 14 is considered to be patentable based on 
its dependence on claim 1 1 and for reasons given in connection with claim 5. 
Consequently withdrawal of the Rejection of claims 1-27 is respectfully requested. . 

TV. Added claims 28 and 29. 

Independent claims 28 and 29 are added. Claim 28 is a combination of 
claim 2 and claim 1 (prior to the claim 1 amendment made herein). Claim 29 is a 
combination of claim 6 and claim 1 (prior to the claim 1 amendment made herein). 
These claims are considered to be patentable for the reasons given in connection with 
claims 2 and 6 respectively. 

In view of the above amendments and remarks, Applicants submit that 
the Application is in condition for allowance, and favorable reconsideration is 
requested. 

Respectfully jsubmi Ued, 

Date: February 25, 2005 Alexander J. Burke 

Reg, No. 40,425 
Siemens Corporation 732-321-3023 
Customer No. 28524 
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